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I.  Introduction 

A  number  of  high  technology  firms  have  recently  reported  increasing 
delays  in  the  development  of  computer-related  hardware  and  software. 
Experiencing  increasing  product  development  times  and  schedule  overruns, 
one  such  company  commissioned  a  system  dynamics  study  of  the  management  of 
its  product  developnent  group.   The  purpose  of  the  study  has  been  to 
uncover  potential  sources  for  rising  product  developnent  times  in  the 
company  and  to  identify  those  over  which  management  can  exercise  some 
control . 

The  results  of  the  study  are  interesting  to  consider  in  light  of 
current  perceptions  of  declining  industrial  productivity  in  the  United 
States  and  increasing  question  about  the  efficiency  and  effectiveness  of 
research  and  development  efforts.   The  study  has  demonstrated  that  the 
symptoms  of  what  is  apparently  a  problem  of  declining  engineering 
efficiency  can  be  generated  by  a  pattern  of  decisions  in  the  firm.   This 
paper  describes  the  study  that  supports  this  conclusion  and  analyzes  the 
decision  structures  that  have  the  potential  to  produce  rising  product 
development  times. 

Section  II  of  this  paper  describes  in  more  detail  the  nature  of  the 
problems  addressed  by  the  study  and  discusses  a  number  of  perspectives  on 
such  problems.   Section  III  describes  the  structure  of  the  computer 
simulation  model  developed  in  the  course  of  the  study.   Section  IV  analyzes 
the  causes  for  rising  product  development  times  in  the  model.   Section  V 
discusses  implications  of  these  model-based  analyses  for  the  management  of 
a  development  group  in  the  context  of  rapid  corporate  growth. 

II.  The   Problem 

The   company  on  which   this   research  is  based    is  a  developer  and 
manufacturer  of  data-communications   equipment.      Having   enjoyed   a   real   rate 
of  revenue   growth   in   the   neighborhood   of  thirty-to- thirty-five  percent  per 
year   for   the   past   ten  years,    the   firm  now  encompasses   six  diverse   product 
lines,    including  high-speed   modems,   multiplexers,   intelligent   terminals, 
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and  diagnostic  devices  for  computer  communication  systems.   The  firm 
projects  that  the  personnel  in  the  product  development  group  will  grow  over 
the  next  five  years  at  more  than  twenty  percent  annually. 

Since  1977,  the  company  has  experienced  increases  in  the  time  it 
takes  to  bring  a  product  from  the  initiation  of  development  to  its  first 
shipments.   In  this  period  overruns  in  product  development  schedules  have 
increased  in  frequency  and  severity.   Product  development  times  have  risen 
from  a  norm  of  18-to-24  months  to  as  high  as  30  months,  and  schedule 
overruns  have  gone  as  high  as  nine  months.   Because  the  time  it  takes  to 
develop  a  product  is  essentially  the  delivery  delay  of  a  development  group, 
increases  in  it  can  lead  to  the  loss  of  sales.   Thus  rising  product 
developnent  times  threaten  to  slow  the  traditionally  rapid  growth  of  the 
firm.   Compoimding  the  problem,  from  1977  to  1979  the  company  lost  a  number 
of  senior  development  engineers.   The  reasons  expressed  varied 
considerably,  but  seemed  to  center  on  changes  in  the  character  of  the  firm 
brought  about  by  its  dramatically  rapid  growth:   increasing  administrative 
burdens  on  senior  engineers,  a  large  and  growing  percentage  of  new 
engineers  in  the  developnent  group,  and  the  feeling  that  the  quality  and 
commitment  of  personnel  were  not  quite  what  they  used  to  be. 
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Figure   1:      The   problem   foe  lis :      rising   product 
development   times  and   an   increase   in   turnover  of  senior 
developtient   engineers 
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These  two  dynamic  patterns,  shown  graphically  in  figure  1,  are  the 
focus  of  this  study.   It  is  reasonable  to  suggest  that  they  are  related:   a 
loss  of  highly  productive,  senior  engineers  could  easily  set  development 
projects  back  considerably.   An  influence  in  the  opposite  direction  is  also 
conceivable:   a  prolonged  pattern  of  rising  product  development  times  could 
produce  such  a  pressured  atmosphere  to  meet  schedule  deadlines  that 
engineers  eventually  opt  for  more  comfortable  job  situations. 

Perspectives  on  the  Problem 

Such  patterns  may  be  viewed  as  natural,  unavoidable  aspects  of  the 
dynamics  of  rapidly  growing,  high- technology  industries.   A  number  of 
experts  in  the  data-communications  industry  trace  recent  overruns  in 
product  development  schedules  to  the  shift  to  more  sophisticated 
technology — from  LSI  (large-scale  integrated  circuitry)  to  VLSI  (very 
large-scale  integration).   "At  the  heart  of  the  problem,"  says  Business 
Week  [l],  "are  the  complex  logic  circuits  that  make  up  the  computer 
processor.   As  more  and  more  of  this  circuitry  is  squeezed  onto  a  single 
high-density  chip,  it  becomes  tougher  to  correct  design  flaws.   Once  the 
circuits  are  cased  in  silicon,  they  cannot  be  changed  without  redesigning 
and  refabricating  the  entire  chip,  a  process  that  takes  at  least  four  to 
six  weeks."   So  product  development  times  are  seen  to  rise  for  two  likely 
and  related  reasons:   increasingly  complex  products  inherently  take  longer 
to  design,  and  undiscovered  errors  in  the  new  VLSI  technology  take  longer 
to  correct.   Fierce  competition  for  development  engineers  highly  skilled 
and  experienced  in  LSI  and  VLSI  design  and  manufacture  is  a  natural 
consequence.   Turnover  is  likely  to  be  increasingly  high,  as  engineers  are 
lured  from  company  to  company  by  ever  more  attractive  job  situations.  [2 J 

If  the  problems  are  industry-wide  and  essentially  beyond  managerial 
control,  no  one  firm's  share  of  the  market  is  threatened  by  a  pattern  of 
rising  product  development  times.   Everyone  will  reach  the  market  somewhat 
later  than  advertised,  and  no  one  will  be  able  to  capitalize  permanently  on 
the  development  delays  of  others.   If,  however,  there  are  aspects  of  the 
phenomenon  that  are  potentially  within  the  control  of  corporate  management, 
then  those  companies  that  learn  the  quickest  stand  to  reap  considerable 
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benefits  in  market  share  and  revenues.   Our  client  company  wished  to 
investigate  the  point  of  view  that  some  aspects  of  the  problem  could 
actually  be  exacerbated  by  its  own  R&D  management  policies.   It  requested  a 
study  focused  internally  on  the  operation  of  its  development  group. 

A  wide  range  of  perspectives  on  the  problem  can  be  brought  together 
by  the  following  simple  mathematical  model,  essentially  a  definition  of  the 
development  time  of  a  product: 

^  ,   T     a.  .  .        tasks  in  product  development      ,^^ 

product  development  time  =  7 : /  ^    , rr — i ,*^  ^  . — — — ,   (1  ) 

^  (engineers/ product;  *  productivity 

where  a  "task"  is  some  arbitrarily  defined  unit  of  work  and  productivity  is 
measured  in  tasks  per  person  per  unit  time.   The  following  equivalent 
identity  neatly  shows  how  the  fractional  growth  rates  of  these  quantities 
consequently  must  relate: 

PPT   ^  PER     ENG   _^   PDEV     PROD  /  x 

PDT     PER   ~   ENG   ""   PDEV  ~  PROD'  ^^ 

where 

PDT  =  product  developnent  time  (months) , 

PER  =  product  engineering  requirement  (tasks  per  product) 

ENG  =  engineers, 

PDEV  =  products  under  developnent. 

PROD  =  productivity  per  engineer  ( tasks/ engineer/month) , 

and  dots  denote  derivatives  with  respect  to  time. 

If  product  developnent  times  are  rising,  then  the  right-hand  side  of  this 
identity  (2)  must  be  positive,  which  is  to  say  the  fractional  growth  rates 
of  the  product  engineering  requirement,  the  number  of  engineers  in  the 
group,  the  number  of  products  under  development,  and  the  average 
productivity  per  engineer  are  out  of  balance.   To  keep  product  development 
times  constant  in  the  face  of  rising  technological  complexity  and  rapid 
corporate  growth,  the  terms  in  (2)  must  net  to  zero. 

All  perspectives  on  the  immediate  causes  of  rising  product 
development  times  can  be  found  in  this  identity.   Because  of  the  complexity 
of  the  problem  and  the  drive  to  delve  deeply  into  its  underlying  causes, 
most  attention  has  been  focused  on  single  terms  in  (2).   Considerable 
research  has  focused  on  productivity  issues,  for  example.   The  identity 


D-5321-1  5 

shows   that   if   fewer   engineering   tasks    per  month   per   engineer  are   completed, 
then  even  if  the   complexity  of  the   development   effort   remains  constant 
product  development   time   can   rise.      Management   experience   and    the   R&D 
literature   suggest  numerous   factors  have   the   power   to   influence 
productivity.      Cotiis   and   Dyer   [3],    for   example,   discuss   twelve  dimensions 
of  project  management   that   correlate   significantly  with   the   efficient  use 
of  product  development   resources,    including   stability  of   product 
specifications,   coordination  and   cooperation,    clear  lines  of  authority  and 
responsibility,    and   comprehensive  group  communication.      Stahl   and   Steger 
[4 J   relate  an  engineer's   productivity  to   characteristics  of  the   individual 
and   his   or   her  development  group,    including  such   things  as   perceptions  of 
pressure   to   produce,   participation   in  goal-setting,    commiinication  with 
other   professionals,    length  of   scientific   employment   (they   found   a   negative 
correlation),    and   perceptions   of  the   project   leader's   empathy  and 
evaluation  of   the   work.      Allen   [5]   has  documented    the   importance  of   the 
role   of  communication  networks.      Though  not  directly  addressing    the   problem 
of  rising   product   development   times,    these   studies   shed   light  on 
determinants  of  the  behavior  of  the   productivity  term   in   (2)   and    thus 
suggest   potential    sources  of  our   problem. 

Another   trend    in   the   literature   has   focused    on   the   product 
engineering   requirement.      Rising    technological   complexity  and    the  need    for 
rework  fall    into   this  category.      Sharp  increases   in   technologicial 
complexity  such  as   those   involved    in   the   new   VLSI   technology   invalidate 
some  of  the   old   rules  of  thumb  of  project   planning   and    scheduling,   making 
it  difficult    to   estimate   accurately   the  man-months  of   product  development 
required.      In   addition   the   difficulties  in  debugging   the  more  complex  VLSI 
circuitry,    for   example,    have   the   power   to  generate   the   need    for 
considerable   rework.      Both   can   lead    to   overruns   in   the    the  man-months   of 
product   engineering   required.      Rework   is   especially  troublesome.      The 
longer  an  error  goes  undetected,    the  more   extensive   the  necessary  rework 
and    the  greater   the   rise   in   the   product   engineering   requirement.      Changing 
design  specifications  after  development  has  begun   also   generates   the   need 
for   rework.      Cooper   [6]   describes  a   large   system  dynamics   study  of  cost 
overrims   in  a   shipbuilding   contract.      The    study  showed    that   the   rework 
required  by   frequent  design  changes   imposed  by   the   Navy  were   the  major 
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contributing  factor  to  a  $500  million  dollar  overrun.   (A  suit  was  settled 
out  of  court  for  $447  million.)  Undiscovered  rework  is  also  the  focus  of 
the  simple  R&D  project  models  in  Roberts  [v]  and  Richardson  and  Pugh  [s]. 

The  work  described  in  this  paper  provides  an  integrating  framework 
for  the  perspectives  on  rising  product  development  times  captured  in  (2) . 
The  computer  simulation  model  developed  as  a  basis  for  the  research  places 
the  interactions  between  productivity  and  technological  complexity  in  the 
context  of  a  comprehensive  manpower  planning  and  product  scheduling 
structure.   The  whole  is  designed  to  look  and  behave  like  the  product 
development  group  of  a  high  technology  company.   As  a  result  of  this 
integration,  the  work  has  illuminated  sources  of  rising  product  developnent 
times  that  have  not  been  previously  acknowledged  in  the  literature  —  in 
particular,  sources  related  to  the  middle  two  terms  of  the  identity  (2). 
In  the  context  of  rapid  corporate  growth  the  coordination  of  manpower 
planning  and  product  scheduling  is  apparently  more  difficult  than  assumed. 
Our  work  suggests  that  the  lack  of  adequate  coordination  is  a  potentially 
potent  source  of  rising  product  development  times. 

Several  characteristics  of  the  system  dynamics  approach  help  to 
explain  why  this  work  has  resulted  in  a  slightly  different  view  of  rising 
product  development  times.   First,  the  approach  focuses  on  patterns  of 
behavior  over  time,  and  the  time  frame  encompasses  both  short-term  and 
long-term  phenomena.   Second,  the  major  modeling  effort  is  focused  on 
creating  a  very  strong  correspondence  between  model  structure  and  what  are 
deemed  to  be  essential  features  of  the  real  system.   Flows  and 
accumulations  of  people  and  material  in  the  real  system,  for  example,  are 
carefully  conserved  in  the  model.   The  conservation  tendency  led  naturally 
to  a  careful  allocation  of  an  engineer's  time  to  various  engineering  and 
nonengineering  demands.   Finally,  most  importantly,  the  approach  takes  a 
cybernetic  view  --  the  presiomption  that  the  behavior  of  a  complex  system  is 
a  consequence  of  its  "information  feedback  structure."  The  following  brief 
discussion  of  the  structure  of  the  model  in  this  study  will  expand  these 
notions. 
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III.   Modeling  the  Process  of  Product  Development 

A  number  of  system  dynamics  models  relating  to  the  management  of  R&D 
projects  have  been  developed  and  used  for  policy  analysis.  [6]  -  [ll]   The 
model  in  this  study  differs  from  these  in  that  it  does  not  trace  the 
lifecycle  of  a  single  project;   rather,  it  reproduces  the  dynamics  of  a 
development  group  over  a  ten  year  period  as  a  continuous  stream  of  products 
are  developed  and  placed  into  production.   The  model  focuses  on  the  number 
of  products  under  development,  the  use  of  resources  required,  and  an 
aggregate  average  product  developnent  time.   In  addition,  the  model  differs 
from  past  modeling  efforts  by  placing  R&D  dynamics  in  the  context  of  rapid 
corporate  growth.   It  is  intended  to  replicate  the  structure  and  behavior 
of  a  product  development  group  growing  initially  at  thirty  percent  per 
year. 

Model  Overview 

The  model  contains  more  than  150  equations  representing  a  complex 
structure  of  interacting  variables  and  interconnected  feedback  loops 
assumed  active  in  a  corporate  product  development  group.   It  was 
constructed  over  the  course  of  a  year  with  the  aid  of  the  senior  director 
of  business  planning  in  our  reference  company  in  consultation  with  the  vice 
president  for  development  and  a  senior  director  of  development.   A  complete 
description  of  the  model  is  not  possible  here.   Instead,  those  pieces  of 
model  structure  that  support  the  insights  it  has  helped  to  generate  will  be 
presented  in  detail.  [12] 

As  shown  in  figure  2,  the  model  consists  of  four  major  sectors 
focusing,  respectively,  on  engineers,  managers,  product  development,  and 
revenue  and  budget.   These  sectors  are  sufficient  to  capture  the  major 
dynamics  of  the  terms  in  the  simple  identity  (2)  and  to  include  feedback  to 
and  from  the  market  for  the  firm's  products.   The  engineer  sector  (70 
equations)  traces  the  flow  of  engineers  as  they  are  hired  into  the  firm,  as 
they  become  assimilated  and  develop  into  highly  productive  senior 
engineers,  and  as  they  are  promoted  to  managers  or  leave  the  firm.   The 
sector  monitors  pressures  that  have  the  potential  to  cause  quits  of  senior 
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Figure   2:      Overview  of  the   structure   of  the  model 


engineers   and   keeps   account  of  competing  demands   for  an  engineer's   time. 
The  manager   sector   (23  equations)    hires  and   promotes   people  into  managerial 
and   coordinating   positions   and    traces   the   effects  of  managerial   experience 
on   the   productivity  of  engineers.      In   the   product  developnent   sector   (29 
equations)    products   are   initiated,   developed,    completed,    passed   into 
production,   and   eventually  drop  out   of  production  as   they  become  obsolete. 
This   sector   computes   an  engineers'    estimated    product  development   time,    the 
compromise    target  development   time   settled   on  in  light   of  perceptions  of 
market   needs,    and    the   actual   product  development   time   that   results   from   the 
dynamics   of  the   entire   development  group.      The    sales  and    revenue    sector   (30 
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equations)    contains   a   simplified    treatment   of  a  growing  market.      The   firm's 
market    share   responds   to   the   quantity  and   quality  of  the   firm's   output, 
relative   to   its   competitors.      A  percentage  of   the   revenues   from   products   in 
production   is   allocated    to   the  development   group  and   used    for   salaries   and 
product   development.      With   the  market   effects   assumed   in   the  model  a   closed 
loop  of  action   and   information   exists:      the   operations   of  the   developnent 
group  affect    revenues,    and   the   resulting  growth  in   revenues   affects   the 
growth  of  people   and   products   in  the  development   group. 

The   internal  operations  of   the   firm  are   influenced  by   three   exogenous 
factors:      a  gradually  growing   pool   of  engineering   talent,    a  growing  market 
for   the   firm's   products,    and   increasing   competition   for   the   firm's  market 
share.      These   exogenous   influences   can  be   varied    to   test   different 
scenarios.      When  kept    the   same   in  different   computer   simulations,    they 
provide   a  common   background   against   which   to   test   different  management 
policies   within   the   firm.      The  dynamics  of  all   of   the   remaining  variables 
in   the  model   are   determined    endogenously,    that   is,    internally,    by  the 
assumed   decision   structure  of   the   firm. 

Influences   on  Productivity 

Six    factors   in   the  model   directly  affect   engineering   productivity: 
the   basic   quality  of   the   engineering  group,    average   aggregate   engineering 
experience   in   the   firm,    supervisory  activities   required   of  engineers,    team 
size,    requirements    for  nonengineering  activities   related   to   organization 
and   communication,    and    pressures   arising   from   developnent   schedules.      These 
influences   are   used   to   compute  a  number  of  "full-time  equivalent 
experienced    engineers,"    the   fully  productive   fraction   of  the   total   number 
of   engineers.      The   concept  of  an   "FTE"    is  a  modeling   convenience  defined    to 
represent    the  mythical   senior   engineer  who   spends   every  minute   of  every 
working  day   in   fully   productive   engineering  activities.      Product 
development   time  is   then   simply  the   result   of  dividing   the  number   of 
man-months  of  actual   product   engineering   required  by   the  number  of   full- 
time   equivalent   engineers   per  product. 
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Because  declining  productivity  is  one  of  the  most  likely  sources  of 
rising  product  development  times,  the  actual  equations  assumed  in  the  model 
will  be  presented  here.   Product  developnent  time  is  computed  essentially 
as  in  ( 1  ) : 

PDT  =  PER/FTEPP  (3) 

where 

PDT        =   product   development    time   (months), 

PER       =   product   engineering   requirement   (man-months), 

FTEPP  =   full-time  equivalent   engineers   per  product   (people). 

To   determine   the  number  of   full-time  equivalent   engineers   in   the 
developnent   group,    three   competing   demands   for  an   engineer's   time  are 
recognized   in   the  model:      engineering,    supervising   engineers   new   to   the 
firm,    and   handling   a  mix   of  non- engineering   activities   called    the 
"organization  and   communication  burden"   of   the   developnent   group  (described 
in   section   IV) .      The   computation   is 

FTEPP    =   ETS  *  EF  *  ESPP   *  EQEP   *  EIP  (4) 

where 

FTEPP  =   full-time  equivalent   engineers   per  product, 

ETS  =   effective   team   size   ( people/ product) , 

EF  =   engineering   fraction   (see   below), 

ESPP  =   effect  of   schedule   pressure   on   productivity, 

EQEP  =  effect   of  the   quality  of  engineers   on  productivity, 

EIP  =   effect  of   incentives   on   productivity  (a   policy   parameter). 

Essentially,    the  number  of  full-time  equivalent   engineers   per  product   is 
equal   to   the  actual  number  of   engineers   per   product,   multiplied  by  the 
fraction  of  these   people   that   are   "full-time,   experienced   equivalent 
engineers,"   and  modified    further  by  effects   on   productivity   from   short   and 
long-term   schedule   pressure,    the   overall   quality  of  the   engineering   group 
in   the   firm,    and   a   potential   effect  of  an   incentives   policy. 
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The   engineering   fraction   EF   translates   the  number  of  inexperienced 
and    experienced    engineers   in   the  model    into   an   equivalent   number   of 
experienced   engineers   and   subtracts  out   the    fraction  of   time   engineers 
spend   in   supervisory  and   organization  and   communication  activities.      The 
equation  is 

EF   =  EFEP  -  FEX*FMHS   -  FEOC  (5) 

where 

EF  =  engineering  fraction, 

EFEP  =  effect  of  fraction  experienced  on  productivity, 

FEX  =  fraction  experienced, 

FMHS  =  fraction  of  experienced  manhours  to  supervision, 

FEOC  =  fraction  of  an  engineer's  time  in  organization  and 
communication  activities. 


A  Development  Group  as  a  Feedback  System 

In  the  system  dynamics  approach  two  fundamental  concepts  form  the 
focal  points  for  model  conceptualization:   accumulation  processes  --  stocks 
and  flows  of  people  and  material  —  and  feedback  loops  —  closed  paths  of 
action  and  information.   Figure  3  shows  the  principal  accumulations 
(levels)  and  flows  (rates)  assumed  in  the  model.   (A  number  of  other 
accumulations  that  appear  in  the  model  as  delays  or  averaging  processes  are 
not  shown.) 

The  model  separates  both  engineers  and  managers  into  "inexperienced" 
and  "experienced"  pools  so  that  a  number  of  productivity  effects  can  be 
represented.   Supervision  of  new  engineers  by  senior  people,  for  example, 
creates  two  opposing  effects  on  engineering  productivity:   increased 
supervision  speeds  the  assimilation  of  new  engineers  and  shortens  their 
period  of  lower  productivity,  but  it  pulls  senior  engineers  away  from 
actual  product  development  work.   Both  effects  are  captured  in  the  model. 
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Figure  3:      Principal   levels   (stocks)    and   rates   (flows) 
in   the  model.      [Rectangles   represent   accumulations; 
valve   symbols  represent   rates  of  flow.      All   rates   in 
this   figure  vary  over   time   in   response   to   other 
influences  not  diagrammed.] 


The   concept  of   feedback  arises  naturally  in  analyzing  cause   and 
effect  sequences   that  appear   to   be   related   to   the   problems  of  rising 
product  development   times   and    increasing  quits  of   senior  engineers. 
Supervision  again   provides  a  good   example.      Suppose   the   firm   experiences  an 
increase   in  quits   among   senior  engineers   who   spend   some   fraction  of  their 
time  providing   engineering  guidance   to  others.      The   loss  would  mean   that 
less  day-to-day   supervisory  time   would   be   available   to  newer  engineers.      As 
a  consequence,    it   should   take   longer   to   assimilate  new  engineers   into   the 
firm  —   a   longer  apprenticeship  or  development   period  before  a  new  person 
reaches   the   productivity  of  a   senior  engineer.      Thus,    the   rate   of  flow  into 
the    pool   of   experienced    engineers   would    tend    to    slow  up.      In   sum,    an 
increase   in  the   outflow  from   the   experienced   pool   tends   to  decrease   (other 
things  being  equal)    the   inflow  to   that   pool,    further   exacerbating   the  drop 
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in  senior  engineers  caused  by  the  increase  in  quits.  This  self- reinforcing 
process,  called  a  positive  feedback  loop,  is  shown  in  figure  4  side-by-side 
with  another  loop  having  the  same  self- reinforcing  character. 


Figure  4:   Self- reinforcing  (positive)  feedback  loops 
in  the  supervision  of  new  engineers  by  senior 
developnent  engineers. 


The  feedback  perspective  illuminates  two  general  types  of  processes 
at  work  in  any  complex  system  —  those  that  are  self-regulating  and  those, 
like  the  supervision  loop,  that  are  self- reinforcing.   The  model  in  this 
study  was  formulated  from  the  point  of  view  that  all  decisions  are  made  in 
the  context  of  feedback.   Some  aspect  of  the  system  is  perceived;   change 
comes  frcm  the  desire  to  move  the  system  closer  to  some  desired  state; 
decisions  are  made  to  bring  the  actual  state  of  the  system  closer  to  the 
desired;   the  actions  taken  alter  the  state  of  the  system,  giving  rise  to 
new  perceptions  of  the  system.   Such  a  closed  loop  of  action  and 
information  is  called  a  feedback  loop,  because  information  eventually 
"feeds  back"  to  its  point  of  origin,  affecting  future  perceptions  and 
actions.   The  model  developed  in  this  study  contains  hundreds  of  such 
loops.   The  dynamic  behavior  of  the  system  is  a  consequence  of  the  complex 
interactive  structure  they  form. 
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The  decision   to   introduce  a   product    for  develojment   is   embedded   in 
numerous   feedback  loops,    and   is   an  important   determinant   of  the  behavior  of 
the   system  over   time.      The  decision   is   based   upon   the  current   workload   in 
the   developnent   group,    the   availability  of  resources,    project   completions, 
and   growth  goals.      The  model   equation   states: 

PGEN   =    (DPDEV-PDEV)/PDEVAT   +  COMP   +  GP*PDEV,  (6) 


where 


PGEN  =  product  generation  rate  (products/month), 

DPLEV  =   desired   products   in  developnent, 

PDEV     =  products   in  development, 

PDEVAT=   adjustment   time   for   products   in  developnent   (months), 

COMP     =   product   completion  rate   (products/month), 

GP  =   growth   factor   for   products   in  developnent. 

Essentially,    the   equation   states   that   new  products  are   added   to   the 
workload   of   the  development   group  when  old   ones   are   completed   (COMP)    and 
when  additional    ones   are   necessary  to   keep  up  with  planned   growth 
(GP*PDEV).      The   term      (DPDEV-PDEV) /PDEVAT     represents   pressures   in   the 
decision  process   that   adjust   the   rate   of  introduction   of  new  products   to 
the   availability  of  developnent   resources.      It   pushes   the  actual 
introduction   of  products   above   or  below  the  base    rate   (COMP  +  GP*PDEV) 
depending   upon   how  PDEV  ccanpares   to   its   desired  value,    DPDEV.      The   latter 
is   an  aggregate   concept   representing   the   firm's  perception   of  the  number  of 
products   in  development   that   is   necessary   to  meet   its  market   needs   and   that 
can  be   supported   by  the  manpower  and    revenue    currently  available   to   the 
developnent   group.      The   parameter  PDEVAT  reflects   how  closely  management 
monitors   the  workload   in   the  development   group  and   how  rapidly  it   takes 
action   to   bring  actual   conditions  more   in  line  with  desired.      In  the  base 
case   in   the  model   PDEVAT  is   set   at   24  months,    the   average   product 
developnent   time   at   the   start  of   the   simulation. 


D-5321-1 


15 


A  feedback  loop  is  evident  in  the  first  term  in  this  formulation. 
The  current  number  of  products  in  the  development  group  (PDEV)  is  compared 
to  a  desired  number  (DPDEV).   Any  discrepancy  generates  countervailing 
action  in  the  product  generation  rate:   if  PDEV  is  too  small,  for  example, 
the  adjustment  term  will  be  positive,  and  more  products  will  be  generated 
per  month  until  PDEV  is  brought  up  to  DPDEV.   Figure  5  shows  the  simple 
feedback  loop  represented  by  this  adjustment  term.   The  loop  is  self- 
regulating:   it  continuously  strives  to  adjust  PGEN  to  keep  the  number  of 
products  in  the  development  group  equal  to  the  number  desired.   It  is 
called  a  negative  feedback  loop  because  it  tries  to  negate  or  counteract 
any  change  in  PDEV  from  its  goal,  DPDEV. 
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Figure   5:      Self- regulating   (negative)    feedback  loop  in 
the  decision   to   introduce   products   for  development 


The   formulation   of  PGEN  also   illustrates   a   positive  or   self- 
reinforcing   feedback   loop.      The   positive    feedback   loop  linking   products   and 
revenue    is  among   the  most   important   self-reinforcing   feedback  loops 
associated   with  a   technology-based   company.      Products   in  development 
eventually  become   products   in   production,   which  are   the   source   of  the 
company's   revenues.      Revenues   support    the  budget  of   the  development  group. 
In   our   reference   company,    six-to-eight   percent   of  gross   revenues   go   to   R&D. 
Thus    the  more   revenues  generated,    the  more   engineers,   money,    and    technical 
resources  are   available   for  expanded   product  development.      In   the  model, 
more   revenues   thus  mean  a  higher  niunber  of   products   supportable   in   the 
development  group,    that   is,   a  higher  DPDEV,    and   hence  a  greater  rate   of 
product  generation   (other   things   equal). 
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This  cummulative   expansion  of   products   and   revenues   is   the 
fundamental   growth-producing   loop  of  a   technical   company:     more   products   in 
development   lead   eventually   to  more   products   in   production,    which   produce 
more   revenue;      more   revenue   means  more   resources   for  product  development, 
which  lead    to  more   rapid  generation  of   products   and   a  growing  stock  of 
products   in  development.      The   closed    sequence   of  causes   and   effects   appears 
as   three   loops   in   figure  6.      Each   is   clearly  self-reinforcing:      by 
generating   additional   revenue,   products   in  development   can  lead   to   still 
more   products   in  development. 
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Figure  6:   Self- reinforcing  (positive)  feedback  loops  in 
the  decision  to  introduce  products  for  development 


The  diagram  also  suggests  that  these  loops  can  be  self-reinforcing  in  the 
opposite  direction.   In  a  sustained  market  decline,  for  example,  products 
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in   production   produce  declining   revenues,    leading   perhaps   to   fewer 
resources   available   for  product   development,    leading   to   a   cutback  in 
products   in  development,    eventually   fewer   products   in   production,    and 
perhaps   still   greater  declines   in   revenue,      (it    is   likely  that   other   loops 
representing  more   complex   corporate   decision-making  not   shown  in   this 
figure   would   intervene   in   such  a   situation,    however,    perhaps   raising   the 
fraction  of   revenues   going   to   developnent . ) 

Further  details   of  the  model    structure   assumed    will   be   given   in 
section   IV  when    they  help   support   the   analysis  of  model   behavior  and   policy 
implications . 


IV.        Analyzing   Rising  Product   Development   Times 

The   goal   of  a   system  dynamics  modeling   effort   is    to   improve 
understandings   of  the   relationships   between   the   feedback  structure   of  a 
system  and   its   behavior   over   time.      The   simulation  model   is   a   laboratory 
tool.      Ey   altering   parameters,    changing   the   strengths   of  assumed   effects, 
or  deactivating   pieces  of  model   structure  we   learn  the   connections   between 
model    structure   and    behavior.      With  care,   and   a  number   of  iterations   of 
conceptualization,    formulation,    testing,    and   refinement,    we   try   to  move 
toward   understanding   the   connections   between   the   structure   of  the   real 
system  and   its   behavior.      Thus   the  base   run  of   the  model   is   best  viewed   as 
a   reference   against   which   to   compare   other   runs   that   differ   in  varying 
degrees   in   parameter  values   and    feedback   structure.      We   shall   begin  by 
showing   important   aspects   of  the  base   run.      Then  various  model   assumptions 
will   be   alterned   in  a   sequence  designed   to   reveal    their   relationship   to 
rising   product   developnent    times. 

Figures  7   and  8   show  that   the  base   run   of  the  model    reproduces   the 
problem  behaviors   of   interest.      Figure  7   shows   a   pattern  of  rising   product 
development   times   set   against    the   engineers'    projections,   management's 
desired    product   development    time   (assumed    constant   at   24  months),    and    the 
compromise   upon  which  engineering   and   management   decisions   are  based.      The 
average   product   developnent   time    rises   from     24  months   to  28  months   after 
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48  months  of  simulated  time,  declines  a  bit  for  the  next  24  months,  and 
then  resumes  its  rise  for  the  remainder  of  the  run.   Engineer's  projections 
follow  a  similar  pattern,  displaced  somewhat  in  time  due  to  delays  in 
perceiving  changes  in  engineering  efficiency.   The  compromise  product 
development  time  is  a  balance  between  the  engineers'  projections  and  an 
imwavering  management  goal  of  an  average  of  24  months  per  product  and  thus 
is  precisely  in  phase  with  the  pattern  of  the  engineers'  projections.   By 
itself,  figure  7  tells  us  little  except  that  the  model  is  capable  of 
replicating  the  problem  of  periodic  increases  product  developnent  times. 

Figure  8  shows  the  fraction  of  senior  engineers  leaving  the  firm  each 
month,  along  with  the  three  quit  pressures  generated  endogenously  in  the 
course  of  the  simulation.   The  dominant  pattern  in  the  figure  is  the  rise 
in  the  quit  pressure  from  the  "administrative  burden"  on  senior  engineers 
and  the  apparently  related  fifteen  percent  rise  in  the  fraction  of  senior 
engineers  leaving  the  developnent  group.   The  quit  pressure  peaks  around 
month  48,  declines  back  to  normal  by  month  90,  and  then  appears  to  begin 
another  rise  as  the  simulation  ends.   It  represents  the  tendency  of  some 
engineers  to  move  elsewhere  if  they  perceive  an  unwelcome  amount  of 
administrative,  managerial  work  has  been  falling  their  way,  pulling  them 
away  from  the  engineering  tasks  they  are  expected  to  do  and  want  to  do.   As 
the  graph  of  quit  pressure  from  schedule  pressure  indicates,  a  small 
portion  of  the  increase  in  quits  is  due  to  persistent,  long-term  pressure 
resulting  from  the  overrun  of  product  developnent  times.   A  third  potential 
source  of  inreasing  quits,  the  quit  pressure  from  "experience,"  reflects 
the  possibility  that  senior  engineers  might  be  moved  to  transfer  if  they 
perceive  the  experience  level  or  quality  of  recent  hires  has  changed  the 
traditional  character  of  the  firm.   Because  the  relative  fractions  of 
inexperienced  and  experienced  engineers  change  very  little  in  the  course  of 
the  reference  run,  the  quit  pressure  from  experience  changes  very  little 
relative  to  the  other  quit  pressures.   It  thus  appears  as  a  constant  equal 
to  1  throughout  the  simulation. 

Since  the  peaks  in  figure  8  occur  at  nearly  the  same  point  in  time  as 
the  start  of  the  leveling  off  of  productive  development  time  in  figure  7, 
the  phenomena  in  the  two  plots  appear  to  be  related  in  the  model,  but  the 
relationship  is  not  clear  from  these  plots  alone. 


D-3521-1 


19 


TiM£" 


t>»vstt>p,HeHT    Tihe 


•it 


Tine    (mcmths) 


Figure  7:   Product  developnent  times  in  the  base  run 


Figure  8:   Quits  and  quit  pressures  in  the  base  run 
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The   patterns   in   figures  7   and  8  were   produced   by  the   internal 
structure   and   behavior  of  a   product   development   group   in   the   context   of  a 
growing  market    for   the   firm's   products,    a  more   slowly  growing   pool   of 
available   engineering  talent,    and  a  growing  competitor  sector  vying   for 
market    share.      In   addition,    in   the   reference   run   the   firm   consciously  opts 
for  developing   technologically  more   complex   products   requiring 
progressively  more  man-months   of  product   engineering.      However,    increasing 
technological   complexity   is   not   a   source  of  the   rise   in   product  development 
time   in   this   run.      The   pattern  of  product   development    time  is   exactly  the 
same  when   the   product   engineering   requirement   is  held   strictly   constant   in 
the  model.      That   invariance   is   the   result   of  several    optimistic 
assumptions.      The   reference  run  of   the  model   assumes   that   engineers   can 
correctly  perceive   the  number   of  man-months   of  engineering   required    to 
develop  a   product  —   no   bias,    no   perception  delays,    and   no   intentional 
under-    or  over- estimation.      If  greater  product   complexity  means   a 
proportionally  greater  need   for  rework,    for   example,    the  model   in   the 
reference   run   assumes   the   need    is  anticipated    and   project   teams   staffed 
accordingly.      The   reference  run  also   assumes   that    project   teams   can  be  made 
larger  without   loss   of  engineering   efficiency.      As   team   size   varies   from     4 
at   the   start   of   the  run   to  17  by  the   end  of  the   ten-year   period,    this 
assumption   is   tantamount    to   assuming   that  management   at   all   levels   in   the 
development   group   is  very   skillful.      These  optimistic   and  debatable 
assumptions   were   taken  in   the   reference   run   in  order   to   focus   first   on 
other,    less   obvious,    sources  of   rising   product  development   times. 

Figure  9   shows   the  behavior  of  product   developnent    times   in   four 
different   simulations   representing  different  management   policies  within   the 
development   group.      In   each  of  these   runs   the   growth   rates   of  the  market, 
the   engineering   labor   pool,    competitors,    and   the   product   engineering 
requirement   are   the   same  as   in  the  base   run.      The   following   discussion 
analyzes   the   reasons   for   the   successive   improvements   evident   in   the  runs. 
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Figure  9:   The  behavior  of  product  development  time 
in  the  base  run  and  three  policy  simulations: 

A  -  Revised  promotion  policy 

B  -  Reducing  overcommitment 

C  -  Using  estimates  of  engineering  efficiency 


Promotion  Policy 


The  difference  between  run  A  and  the  reference  run  is  a  single  change 
in  the  promotion  and  hiring  policy  of  the  firm.   In  the  reference  run  the 
firm  obtains  its  managers  in  the  development  group  largely  from  its  own 
group  of  senior  engineers.   Specifically,  throughout  the  run  a  constant  90 
percent  of  the  managers  acquired  by  the  firm  are  drawn  from  the  firm's  own 
engineers,  and  10  percent  are  hired  from  outside  the  firm.   In  the  policy 
run  A,  the  firm  begins  the  run  acquiring  only  70  percent  internally,  and 
then  deliberately  lowers  that  percentage  as  necessary  to  keep  the  growth 
rate  of  the  pool  of  senior  engineers  near  the  target  growth  rate  of  the 
developnent  group.   By  the  end  of  the  run  only  about  58  percent  of  the 
firm's  managers  are  being  acquired  by  promotion.   In  the  base  run  the 
promotion  rate  was  determined  solely  by  the  need  for  managers.   In  the 
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policy  run   information  about   the   level   of  senior   engineers   (its   growth 
rate)    is   taken   into   consideration.      The   promotion   rate   depletes   the 
engineering   pool,   but   the   pool   now  influences   the   promotion   rate,    thereby 
creating   another   feedback  loop  of  action  and   information   in   the   system. 

It   is   probably   unrealistic    to   assume   that  a   firm   would   acquire   a 
fixed    fraction   of  its  managers  by  promotion.      It  may  also   be   unrealistic   to 
assume  a   firm   takes   the  growth   rate   of  its   engineering   pool   into 
consideration  in  deciding   from  where   to   draw  its  managers.      The   value    of 
the   reference  run   and    policy  run   A  is   that   they  highlight  a   fundamental 
aspect   of  the   finn's   problem.      Skilled   development   engineers   are   hard    to 
come  by;      every   one   promoted   into  a   nonengineering ,   managerial   position 
must   be   replaced,    and   each  is   likely  to   be   replaced   by  someone   initially 
less   experienced   and    productive.      A  high   rate   of  internal    promotion   into 
managerial    ranks   in   the   face   of  severe   competition   in   the   industry  for 
engineers   tends   to  maintain  a   relative  young,    less   experienced,    and   less 
productive   engineering   group.      Two   pressures   lead   to   the   tendency  to 
promote  highly   productive   senior   engineers  out   of  engineering:      the 
personal   desire   to   advance   in   the   corporate   ranks,   and    the   scarcity   of 
people   in   the   industry   skilled   in  managing  high- technology   product 
development   work.      Policy  run   A  reinforces   the   long    recognized   need    for  a 
technological   ladder  of   advancement   as   well   as  a  managerial   ladder. 

Reducing   Overcommitment 

Run   B  in   figure  9   includes   the  variable   fraction   of  managers  acquired 
by   promotion   from  run   A,    and   adds   what   ammounts   to   increased   attention   to 
coordination  of  the   number   of  products  under  development,  .their  average 
engineering   requirement,    and   the  number  of   engineers   in  the  group. 

The  assumptions   in   the  base   run   reflect   a  number  of  pressures   that 
can  combine   to   overextend   the   resources   of  a  developnent   group.      Management 
experience   and    the   R&D  literature   [13]   show  that   some  amount   of  pressure   is 
necessary   for   efficiency.      The   general   wisdom   is    that   work  will    expand    to 
fill   the   time  provided   for  it,    so  management   wants   to   provide  no  more   than 
what   it   perceives   to   be   the  minimvun   to   do   the   job   well.      By  itself   that 
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pressure   for   efficiency   is   healthy  and   does   not   necessarily   lead   to 
overcommitment.      But    there   are   potential   systemic   characteristics   that   can 
push  beyond   efficiency,    to   overcommitment.      Without   accusing  any  one 
specifically  as   the   source,    the   follovdng   combine   to   create   pressure   that 
is   hard    to   resist: 

0        the  belief   that   the  more   products   initiated    in   the   developnent 

group,    the   greater   the   rate   at   which   they  will   emerge   as   revenue- 
generating   products   in  production; 

0        the   tendency   to   remove   all   slack   from   estimates  of   product 
engineering   effort   required; 

0        no   excess   engineering   capacity  to   deal   with  an   overrun  without 
disrupting   other   projects; 

0        not   planning   in  excess   capacity  to   handle   requests   from   the 
marketing   side   of   the   firm   to   refine  a  design  of  a   previously 
developed    product   to   enhance   sales; 

0       budget   constraints   that   tend    to   reduce   hiring  but   not   eliminate   or 
scale   down   product   development   efforts; 

0        the   self-image   of   the   corporation   as   a   leading   innovator  in   a 
rapidly  growing   industry; 

0        the   corporate   perception   or  self-image   of  the  development   group   of 
being   capable   of  doing  a   lot  with   limited    resources; 

0        depending   on  extraordinary  skill   and   effort   in  the   engineering   group 
to   keep   to   schedules  ("its  a   lot   to   expect,   but    Staith   and   Jones  here 
can   do   it,"    or  at   least   they  can  keep   the   project   on   schedule   until 
the   required   team  is   fully  assembled.) 

The   reference   run   reflects   these   pressures   in   the   formulation   of  the 
product  generation   rate,    the  decision   to   introduce   a   new   product   into 
developnent.      The   desired   number   of  products   in  development    is   a  compromise 
between   the  number   supportable  by  current   revenues   and   the  number   that   can 
be   handled   by  the  manpower  in  the   group.      In   the   face    of  constraints   on 
hiring   skilled   engineers,    the  number  of   products   supportable  by   revenue 
tends   to   be   higher   than   the  number   supportable   by  manpower.      In    the   base 
run,    there   is   a   slight   tendency   to   introduce  a   product   before   the   necessary 
team   is   on  hand:      desired    products   in  development   is   biased    slightly  above 
products   supportable  by  manpower  as   long  as   the   revenue   stream   can   support 
the  higher  number.      Figure   10  shows   the   growing   wedge  between   products   in 
development   and    products   supportable  by  manpower   that   results    from 
tendencies   to   acquiesce    to   pressures   to   overextend   the  development   group. 
In   spite   of   the   increases   in   productivity   that   the  model   assumes   as 
schedule   pressure   increases,    the   tendency  to   overcommit   to   too  many 
products   under  development,    if  unchecked,    leads   inexorably   to   rising 
product   development    times. 
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Figure    10:      The   growing   wedge   between   products   in 
development   and   products   supportable   by  manpower  in   the 
base   run. 


In   policy  run   B  in   figure  9,    desired    products   in  development   has   been 
set   to  equal   to  minimum  of   products   supportable  by   revenue   and  manpower. 
But   the   improvement   in   the  determination   of  desired   products   in  development 
would   have   little   effect   unless  management   pays   close   attention   to   it. 
Thus  an  additional    important   aspect   of  the   policy  change   implemented    in   run 
B  is  a   shortening  of   the   time   it    takes   the   firm   to   adjust   to  discrepancies 
between   the  desired   number  and    the  actual   number  of  products   in 
developnent  [see   PDEVAT  in  equation   (6)].      With  an   adjustment    time   for 
products   in  development    of  6  months   instead    of  the  base   run's  24  months, 
the   improved   determination  of  desired   products   in  developnent   essentially 
eliminates   the   growing   wedge   shown   in   figure   10.      The  development   group  is 
corresponding   less    overextended   and    product   developnent    times   decline   as 
shown   in   run    B  in   figure  9. 
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It   should   be   noted   that  a   considerable   portion  of   the   improvement 
comes   just   from    paying   closer  attention   to   the  adjustment    of  products   in 
developnent    to   the  number  desired,    even   if   the  number  desired   is   somewhat 
inflated.      The   reason   is   that   the  adjustment   term   is   just   one   of  three 
terms   in   the   product   generation   rate.      The    fractional   growth   rate   of   the 
number   of  products   in  development   establishes   the  basic   increasing   pattern 
in   products   in  development,    and   it   is   also  a   potential   source   of 
overcommitment   of  the   development   group.      Growth  goals   from   revenue    growth 
targets   are   common,    and   in   the   face   of  a    tight   labor  market    for   engineers 
product   growth  goals  derived    from   revenue    targets   can  easily  exceed    the 
growth  of   engineering  manpower   in   the  group.      The  model   computes  a   growth 
factor   for   the   total   workload    in   the   development   group,    setting   it   equal    to 
the   long-term  growth   trend   in   revenues.      That   growth   in  workload   is   then 
allocated   by  decisions   internal    to   the  model    into   a  growth  in   the   size   or 
technical   complexity  of  products  and  a  growth  factor   for  the  number  of 
products.      The   scarcity   of  engineers   tends   to   pull   the   fractional    growth 
rate   of   people   in   the   developnent   group  below   the   growth   target,   but   the 
growth   target    for  products   remains.      A  tendency  to   overcommit   the   group 
results . 

Run   B  shows    that   a   lack   of  close   attention   to   matching   the  number   of 
products   in  development   with   the   group's   resources   is   a   source   of   rising 
product  development   times.      It   seems   likely  that   an  accurate  match  would   be 
troublesane   in   the   context   of   the   extremely   rapid   corporate  growth   rates 
exhibited    in   some  high- technology  industries. 

Using   Estimates  of   Engineering   Efficiency 

The   further   reduction   in  the   rise   of  product   development   time  shown 
in  run   C   in   figure  9   comes   from   the   use  of   additional   information  in   the 
system,    information   that  may  well   tend    to   be   ignored    or   judged   impossible 
to   obtain   reliably.      That   information  is   an  accurate   estimate   of  recent 
engineering   efficiency  per   person   in   the  development   group.      Run   C  involves 
the   changes   in  rim  B  plus   an   adjustment   of  desired   team   size   to   reflect 
perceived    changes   in   the   average   productivity  of  an  engineer   in   the   group. 
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In  the  base  run  desired  team  size  increases  proportionally  as  the 
number  of  man-months  in  the  product  engineering  requirement  increases,  and 
also  in  response  to  increases  in  schedule  pressure  resulting  from  overruns 
in  product  development  times.   As  the  firm  tries  to  grow  more  rapidly  than 
its  pool  of  available  engineering  manpower,  it  tries  to  expand  the  pool  by 
increasingly  attractive  salary  offers  and,  reluctantly,  by  reaching  further 
into  the  pool,  accepting  not  just  the  top  ten  percent  of  engineering 
graduates,  but  the  top  twenty  or  the  top  thirty  percent.   As  a  result  the 
basic  quality  of  the  engineers  in  the  development  group  declines  slightly 
from  the  start  of  a  run,  causing  a  slight  drop  in  engineering  efficiency. 
(a  more  extreme  drop  in  efficiency  comes  from  increases  in  the  time 
engineers  spend  in  various  nonengineering  tasks,  which  will  be  discussed 
shortly.)   In  the  base  run  that  drop  in  efficiency  is  not  taken  into 
account  in  setting  the  desired  team  size.   Taking  it  into  account,  as  in 
run  C,  increases  the  estimate  of  the  number  of  people  per  product  needed 
and  produces  still  further  gains  in  the  battle  against  rising  product 
developnent  times. 

The  improvement  in  run  C  comes  not  from  hiring  more  people,  however, 
for  the  available  pool  of  potential  hires  is  still  constrained  and  the  firm 
is  doing  as  well  as  it  can.   Instead,  the  more  accurate  estimate  of  desired 
team  size  reduces  still  further  management's  view  of  the  number  of  products 
supportable  in  the  development  group.   (The  equations  for  products 
supportable  by  revenue  and  manpower  are 

PSR  =  RDBE/(DTS*AES) 
PSM  =  TM/DTS 

where 

PSR  =   products   supportable   by  revenue, 

PSM  =   products   supportable  by  manpower, 

RDBE  =  R&D  budget   to   engineers'    salaries   ($/year)  , 

DTS  =   desired   team   size   ( people/ prod uct) , 

AES  =   average  engineer's   salary  ($/person/year) , 

TM  =   total   engineering  manpower  (people). 

Thus   an   increase    in  desired    team   size   lowers   the   estimates    of  the   number   of 
products   supportable.)      The   use   of   information   about   engineering   efficiency 
improves    the   decision   of  whether   or  not    to   introduce   a   product    into 
development.      Throughout   run    C  desired    products   in  development    is    lower 
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than   in   the   previous  runs,    with   the   result   that   the  development   group  is 
not   as   overcommitted .      It   is   interesting   to   note   that   overcommitment   of  the 
developnent   group   can   result    from   the   lack   of  a   piece   of   information  at   a 
certain  decision   point.      Whether   firms  have  access   to   accurate   information 
about   current   engineering   efficiency   is   questionable,   but   if   they  have   it 
and    do   not   use   it   they  are   inadvertantly  creating   part    of  the   tendency  for 
product   development    times   to   rise. 

(Perception  delays   or  downward   bias   in  engineers'    estimates    of  a 
rising   product   engineering   requirement   would  have   essentially  the   same 
effect   as   the   lack   of  information  about   efficiency:      the   desired    team   size 
would   be   set   slightly   too   low.      In   the   context   of  a   shortage   of  available 
qualified    engineers,    the   resulting   tendency  for  product   development   times 
to   rise   would   ccxne    from   inflated   estimates   of   the  number  of   products 
supportable   by  the  development   group's   resources.      The   base   run   of  the 
model   assumed   that   the  current   product   engineering   requirement   is 
accurately  estimated,    so   this   potential   source   of  rising   product 
development    times   was   assumed  away.) 

Incentives 

Policies  aimed   at   improving   productivity  that   do   not   address   the 
underlying   problems   exposed  by  runs   A,    B,    and    C  may  work  in   the  -short   run 
but   will   fail    in  the   long    run.      Suppose,    for  example,    that   a  dramatically 
successful   incentives   program   creates   a   permanent   ten   percent   increase   in 
engineering   productivity.      A  reasonable   expection  would   be   that   product 
development   time   should   rapidly   fall   about   ten   percent,    the   amount   of  the 
productivity  increase.      Tracing   around    the   positive   feedback  loops   shown   in 
figure  6,    one   sees   that   products   would   flow  quicker   into   production, 
revenue   and    revenue   growth  would   rise,    profits  would   rise,   leading   to   an 
increase   in   the   R&D  budget,    and   the   product  generation   rate  would 
eventually  rise   in   response,    producing  more   products   in  development.      With 
the  higher   productivity   the   firm   would   enjoy  higher   revenues   and   a  higher 
revenue    growth   rate,   but   the   tendency  to   overextend    the  development   group 
accordingly  would   remain,    and   product   development   times   would   rise   back  up 
as   a   result.      The   feedback  structure   of  the   system   compensates  naturally 
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for  the   increase   in  productivity   that   stems   from   the  incentives   policy. [l  4] 

The   Organization   and    Communication   Burden 

The   sources   of  rising   product   development   times   discussed   up   to   this 
point   fail    to   explain   the   oscillatory   patterns   evident   in   figure  S.      The 
oscillations   can  be   traced    to   the  way  the   firm  handles   what   we   have  called 
the   "organization  and   communication  burden"   of   the  growing  development 
group.      If   each  engineer  were   to   spend   a  greater   fraction   of  his   or  her 
time   in   non-engineering  activities,    less   productive   engineering   time   is 
available   and   product   development    times   should   rise   as   a   result. 
Conversely,    if  less   time  were   spent   in  non-engineering  activities,    product 
development   times   should   fall.      The  model   exhibits  a   recurring   up  and   down 
cycle   in   the    fraction  of   time   an   engineer   spends   dealing  with   the 
organization  and   communication  burden  of  the  development   group. 
Consequently,    there   is   alternating   upward   and   downward   pressure   on   product 
developnent   times. 

The   organization  and   communication  burden   is   a  highly  aggregated 
concept   in   the  model   representing  a  mix  of  nonengineering  activities 
assumed    to   be   required    in  the  normal   operation  of  a   development   group.      We 
intend    the   concept    to   include   such   things   as   reporting,    coordinating 
members   of  a   team,    coordination  between   teams,   budget   preparation, 
scheduling,    ordering  materials,    handling  crises,    interviewing  and   hiring, 
evaluation   for  salary  and   promotion  decisions,   and   so    on.      It   is   a  wide 
range   of   tasks,    including  many  usually   considered  managerial.      No   attempt 
was  made   to  model    the  detailed    interactions   the  concept   is   intended    to 
represent.      The   organization  and   communication  burden  was   formulated   simply 
to   rise   slightly  more   rapidly  than   the   total   number   of  engineers   in   the 
development   group: 

OCB       =  lc»ENG°^-^^ 

where 

OCB       =   organization  communication  burden  (man-months   per  month), 
ENG       =   total   engineering  manpower  (people). 
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k     =  proportionality  constant  to  set  initial  conditions, 
OCBX  =  an  exponent  slightly  larger  than  1  . 

(The  exponent   OCBX  used  in  the  above  runs  was  1.2.)   The  final  section  of 
this  paper  discusses  variations  on  the  formulation  for  OCB. 

The  Fraction  of  an  Engineer's  Time  in  Nonengineering  Activities 

The  model  assumes  that  a  certain  amount  of  the  organization  and 
communication  burden  must  be  handled  by  engineers.   Fifteen  percent  of  an 
engineer's  time  is  deemed  acceptable,  normal,  and  largely  unavoidable. 
More  than  that,  however,  means  an  unacceptable  loss  of  engineering 
productivity  and,  if  sustained,  an  increase  in  the  tendency  of  senior 
engineers  to  quit  because  of  the  uncomfortable  administrative  burden  placed 
upon  them.   Therefore,  when  it  is  perceived  that  engineers  are  forced  to 
devote  more  than  fifteen  percent  of  their  time  to  nonengineering 
activities,  pressures  build  to  speed  the  acquisition  of  more  managerial  and 
support  people.   The  primary  role  of  managers  in  the  model  is  to  draw  off 
the  burden  of  organization  and  communication  activities  from  engineers, 
increasing  their  productivity  by  leaving  them  freer  to  engineer. 

The  cyclic  pattern  in  the  fraction  of  an  engineer' s  time  in 
organization  and  communication  activities  can  be  traced  to  a  set  of 
negative  feedback  loops  and  perception  delays  involved  in  the  decision  to 
acquire  managers.   Figure  11  shows  an  overview  of  the  structure  assumed  in 
the  model.   (The  equation  for  the  acquisition  of  managers  has  exactly  the 
same  basic  structure  as  the  equation  given  above  for  the  product  generation 
rate:   it  contains  a  term  to  replace  quits  and  retirements,  a  term  for 
growth,  and  a  short-term  adjustment  to  keep  the  number  of  managers  equal  to 
the  number  desired.)   Essentially,  managers  are  promoted  or  hired  in  a 
planned  ratio  to  the  number  of  engineers  in  the  developnent  group.   As  it 
is  perceived  that  engineers  are  spending  too  great  a  fraction  of  their  time 
in  nonengineering  activities,  the  company  deliberately  changes  the  planned 
ratio  of  managers  to  engineers  to  correct  the  situation  and  return  the 
development  group  to  full  productivity. 
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Figure  11:  Structure  underlying  the  cyclic  pattern  in 
the  fraction  of  an  engineer's  time  in  organization  and 
communication  activities 


The  loop  in  figure  11  can  be  thought  of  as  representing  some  aspects 
of  organizational  change:   a  change  in  the  ratio  of  managers  to  engineers 
probably  represents  in  reality  a  shift  to  another  layer  of  management,  or 
to  a  matrix  structure,  or  from  matrix  to  product  line  organization.   There 
are  several  rather  unavoidable  delays  around  the  large  negative  loop  shown 
in  figure  11.   It  takes  the  engineers  themselves  some  time  to  realize  that 
the  time  they  can  devote  to  engineering  has  gradually  declined.   Top 
management  takes  even  longer  to  come  to  the  conclusion  that  past 
orgainzational  policy  should  be  changed.   Finally,  once  the  decision  to 
increase  managerial  capacity  has  been  made,  the  acquisiton  of  managers 
takes  time  as  well.   These  various  perception  and  action  delays  around  the 
negative  feedback  loop  tend  to  produce  a  natural  oscillating  pattern  in  the 
fraction  of  an  engineer's  time  in  organization  and  communication. 
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Figure  12:   Graphs  of  variables  related  to 
organizational  change  in  the  base  rim,  showing  the 
oscillating  pattern  of  the  fraction  of  and  engineer's 
time  in  organization  and  communication  activities. 


Figure  12  shows  the  pattern  of  the  acquisition  of  managers  in  the 
base  run,  together  with  the  related  behavior  of  the  fractional  growth  of 
the  manager  pool,  the  ratio  of  engineers  to  managers,  and  the  fraction  of 
an  engineer's  time  in  organization  and  communication  activities.   The 
sequence  of  events  these  curves  reflect  is  as  follows:   the  burden  of 
organization  and  communication  activities  grows  slightly  more  rapidly  than 
the  development  group.   Additional  managerial  structure  is  acquired  in 
proportion  to  the  growth  of  the  group,  but  because  the  organization  and 
communication  burden  grows  faster  the  planned  ratio  eventually  proves  to  be 
too  small.   The  fraction  of  an  engineer's  time  in  organization  and 
communication  activities  grows.   When  it  is  finally  perceived  that 
productivity  is  suffering  from  having  engineers  deal  with  too  many 
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nonengineering  activities,  steps  are  taken  to  increase  the  planned  ratio  of 
managers  to  engineers  and  speed  the  acquisition  of  managers.   The  planned 
ratio  (the  reciprocal  of  the  quantity  graphed  in  figure  12)  continues  to 
increase  until  it  is  perceived  that  the  fraction  of  an  engineer' s  time  in 
managerial  and  coordinating  activities  has  returned  to  an  acceptable  level. 
Delays  in  acquiring  managers  mean  that  the  group  has  insufficient 
managerial  capacity  for  a  time  and  engineers  have  to  fill  in  even  more  with 
organization  and  communication  tasks.   Perception  delays  mean  that  by  the 
time  the  group  believes  it  has  brought  the  situation  back  to  normal  and  the 
push  to  accelerate  the  acquisition  of  managers  and  support  staff  ceases, 
the  rapid  growth  of  the  company  has  begun  again  to  increase  the  fraction  of 
an  engineer's  time  in  organization  and  communication  activities,  and  the 
cycle  repeats. 

One  result  of  this  ebb  and  flow  of  group  reorganization  is  periodic 
upward  and  downward  pressure  on  product  development  times.   In  the  base  run 
it  coexists  with  the  insistent  upward  pressure  on  product  development  times 
that  stems  from  the  widening  wedge  between  products  in  developnent  and 
products  supportable  by  manpower.   The  graphs  of  product  development  times 
in  figures  7  and  9  are  thus  the  result  of  two  patterns  superimposed. 

A  second  result  of  this  cyclic  behavior  is  the  pattern  of  quits  of 
senior  engineers  shown  previously  in  figure  8.   Organization  and 
communication  activities  interfere  with  what  engineers  would  rather  be 
doing.   The  tendency  of  senior  engineers  to  quit  is  assumed  in  the  model  to 
increase  eventually  as  the  unofficial  administrative  burden  placed  upon 
them  increases.   More,  however,  is  involved  in  figure  8  because  an  increase 
in  quits  of  senior  people  has  some  self- reinforcing  tendencies.   Fewer 
people  to  handle  the  engineers'  organization  and  communication  burden  mean 
that  each  must  absorb  that  much  more.   In  addition,  the  positive  feedback 
loops  associated  with  the  assimilation  of  inexperienced  engineers 
(described  in  figure  4)  become  active.   There  is  less  time  available,  for 
example,  for  the  remaining  experienced  engineers  to  guide  or  advise  new 
people,  so  the  development  of  the  less  experienced  engineers  tends  to  be 
slowed.   At  the  same  time  the  remaining  experienced  people  probably  try  to 
spend  a  bit  more  of  their  time  providing  such  supervision,  so  the  fraction 
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of  time  they  can  devote  to  their  own  engineering  tasks  may  decline.   Both 
tendencies  exacerbate  problems  in  the  group  by  lowering  productivity, 
increasing  schedule  pressures,  and,  if  persistent,  further  increasing  the 
quit  pressure  on  senior  engineers. 


StM  £" 


KuN  0 


Figure  15:   The  patterns  of  product  development  times 
with  the  conditions  of  run  C  (figure  9)  plus: 
D  -  faster  response  to  the  need  for  managers,  and 
E  -  the  assumptions  in  D  with  limitiations  on 
effective  team  size. 


The  pattern  of  product  development  times  labeled  D  in  figure  15  shows 
the  influence  of  the  decision  structure  surrounding  the  acquisition  of 
managers.   The  run  was  produced  with  the  assumptions  of  run  C  in  figure  9 
plus  two  parameter  changes  representing  quicker  organizational  change. 
First,  the  delay  in  perceiving  the  fraction  of  an  engineer's  time  in 
organization  and  communication  activities  was  reduced  from  18  months  in  the 
base  run  to  6  months  in  run  D.   Second,  given  the  perceived  need  for  a 
adjustment  in  the  traditional  ratio  of  engineers  to  managers,  the 
adjustment  in  run  D  takes  place  more  rapidly.   The  quicker  perception  time 
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has   a  beneficial   damping   effect   on   the   oscillations   and   shortens   their 
period.      The  more   aggressive   fractional   change   in   the   traditional   ratio  of 
engineers   to  managers  keeps   the   fraction  of  an  engineer' s   time  in 
organization  and   communication  activities   down  more  but   adds   greater 
instability.      The   result   of  the   two   changes   together  is   a   faster 
oscillation  with   slightly  less   amplitude   than  in  run   C. 

Effective  Team   Size 

A   final    simulation   reveals  an  effect   that  has   been   omitted    in   these 
runs,    partly   to   avoid   obscuring   other  effects   and   partly  because   it   is   a 
matter   of  some  controversy.      Run   E  in   figure   13  shows   the   results   of  run   D 
in  a  more   pessimistic   scenario,    in   which   it   is   assumed   that   the 
productivity  per  engineer   in  large   teams   is   smaller   than   in  small   teams. 
Specifically,    the   effective   team   size   of  a   product   development   team   is 
assumed   in   run   D  to   equal   actual    team   size   up   to  10  people   per  product   but 
then   fall   below  actual   team   size.      Because  of  anticipated   increases   in  the 
number   of  man-months   in  the   product   engineering   requirement,    team   size 
reaches   18   to  20  people  by   the   end   of   these  runs.      Run   D  ends  with  about   21 
people   per  product.      With   the  assumed   diminishing   returns   to   team  size, 
these   21    people   are   as   productive   as   only  about   17.5   people.      The  decline 
in  productivity  emerges   toward   the  end   of  the   run   as   team   sizes   get   large, 
and   productive   development    times   rise   accordingly  as   shown   in   figure   13« 

The   rise   is  not   due    to   the  absolute   drop  in  productivity,    however, 
but   rather   to    the  delay   in   perceiving   engineering   efficiency.      Runs   C,    D, 
and   E  all   assume  that   esimates   of  productivity  are  being   used    to   plan 
manpower  needs   and   decide   on   the  number  of   products   supportable   in   the 
developnent   group.      Placing   the  pessimistic   effective   team   size   assumption 
in   the   base  run   and   runs   A  and   B  would   push  up   product   developnent   times 
considerably  further.      Whether   large   teams  can  be  effectively  managed   with 
no   loss   in   productvity   per   engineer  is   an   unanswered   question  not   addressed 
in  this   study. 
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V.  Policy    Implications 

The   preceding   analyses   show  that   a  pattern  of  rising   product 
development    times   can  be   traced   to   two   relatively   independent   sources   that 
have   little   to   do  with   rising   technological   complexity.      One  has   the 
capability   to   push   up   product   development    times   continually;      the   other 
generates   fluctuations   in  engineering   productivity  that   translate   into 
relatively   short-term   ups   and   downs.      The  cyclic   pattern   is  due   to   the 
structure   involved    in   the   planning   for  and   acquisition   of  managers   and 
support   people.      The   long-tenn    pressure   upward   on   product   development    times 
comes   from   the   structure    of  the  decision   to   introduce   a   product    for 
development.      Both   structures   involve   the   organization's   attempt    to 
coordinate   a  number   of  people  with   the   extent   of  the   tasks   they  are 
expected    to  discharge.      In   terms   of   the   simple   identity   (2)    that   initiated 
this   discussion, 

PPT     _     PER  ENG  PDEV  PROD  ,    . 

PDT     ~      PER      ~      ENG  PDEV      "      PROD'  ^"^^ 

one   structure   seeks   to  match   engineers  and   products   in  development   in  such 
a  way   as   to  hold 

PER  ENG  PDEV 

PER     '*'      ENG      ~      PDEV 

to   zero.      The   other   tries   to   match  managerial   and   support   people   to   the 
organization  and   communication   tasks   of   the   group   so   that   engineering 
productivity  does   not   drop  and 

PROD 
PROD 

does  not   become  negative. 

Table   1    shows   some  additional    information  about   the   simulations   in 
section  IV  that   would   be   necessary   to   evaluate   the   policy  alternatives 
implicit   in   them. 
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Table   1 :      Comparison  of   the   initial   and   final  values  of  selected 
quantities   in  the  base   run  and   five  policy  simulations. 


Run        PDT       MER        PDEV        PGEN        COM? 


PIP       MSH  REV        PVCGP 

(x10^)      (x10^) 


Initial  values  - 
All       24.0      .56 

Final  values  - 


Base  31.2 

A  29.9 

B  27.2 

C  25.4 

D  22.9 


.46 

•  50 

•  50 
.50 

•  57 


6.0 


20.9 
21.7 
19-8 
18.6 
19.0 


25.4      .48       17.5 


3.9 


10.1 
1  1.0 
10.5 
10.2 
11.3 
8.6 


3.0 


8.1 
8.7 
8.7 
8.8 
10.0 


6.4 


.200 


29.4      .227 


31.2 
31.5 
31.9 
33.1 


.239 
.240 
.242 
.250 


19.9 


449.4 
474.5 
477.1 
480.9 
496.0 


0.0 


668.6 
687.7 
689.2 
717.3 
709.5 


8.3       30.9      .239        474.7        701.7 


PDT   =  product  developnent  time  (months) 

MER   =  manpower  efficiency  ratio  (dimensionless 

measure  of  engineering  productivity,  FTE/ENG) 

=  products  in  development 

=  product  generation  rate  ( products/ year) 
COMP  =  completion  rate  (products/year) 
PIP   =  products  in  production 

=  average  market  share 

=  current  revenue  ($/year) 
PVCGP  =  present  value  of  cumulative  gross  profit  over 
the  course  of  the  simulation  ($) 


PDEV 
PGEN 


MSH 

REV 


Table  1  shows  that  the  policy  simulations  A,  B,  and  C  discussed  in 
section  IV  improve  a  number  of  indicators  of  the  health  of  the  company  and 
its  product  development  group.   Each  successive  policy  adds  more  control  to 
product  development  times  and  improves  the  cumulative  gross  profit 
indicator  computed  in  the  model.   Run  D  adds  improves  the  indicators  still 
further,  with  the  apparent  exception  of  the  cumulative  gross  profit 
(computed  as  a  discounted  present  value  over  the  course  of  the  run). 
Profit  in  this  run  is  less  because  the  development  group  has  significantly 
more  managerial  and  support  people  by  the  end  of  the  run  relative  to 
engineers  (managers  =  115,  engineers  =  384  in  D  vs.  98  and  386, 
respectively,  in  C).   The  salary  scheme  assumed  in  the  model  says  managers 
are  paid  more,  so  run  D  winds  up  with  a  more  costly  organizational 
structure  and  profits  are  reduced  even  though  revenues  and  revenue  growth 
are  greater.   (The  profit  figures  should  be  viewed  with  skepticism, 
however,  because  the  model  does  not  assume  a  technological  ladder  of 
advancement  that  pays  very  senior  engineers  as  much  as  managers.) 
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It  is  hardly  surprising  that  policies  that  do  a  better  job  of 
matching  the  size  of  the  engineering  group  to  the  tasks  they  are  expected 
to  accomplish  also  do  a  better  job  holding  down  product  development  times. 
And  it  is  also  not  surprising  that  lower  product  development  times  would 
tend  to  improve  market  share  and  revenues.   More  interesting  is  the 
observation  that  in  run  C  the  completion  rate  of  products  under  development 
by  the  end  of  the  simulation  is  actually  greater  than  in  previous  runs, 
while  the  initiation  rate  (PGEN)  is  less.   Recall  that  the  policy  in  run  C 
served  to  reduce  the  estimate  of  the  number  of  products  supportable  by 
revenue  and  manpower  and,  consequently,  to  slow  the  rate  of  introduction  of 
new  projects.   Less  is  being  put  in  to  the  development  group,  but  slightly 
more  is  coming  out.   The  difference  is  tiny,  but  the  run  appears  to 
contradict  the  feeling  of  "more  in,  more  out"  that  tends  to  pressure 
working  groups  of  all  kinds. 

The  reasons  for  this  behavior  are  to  be  found  in  the  feedback  nature 
of  the  system.   Lower  product  development  times  tend  to  reduce  the 
pressures  that  arise  from  being  behind.   Less  schedule  pressure,  for 
example,  means  less  quit  pressure  on  senior  engineers,  and  that  means  less 
turnover  in  the  engineering  group.   The  engineers  at  the  end  of  run  C  are 
actually  just  slightly  more  productive  than  those  at  the  end  of  run  A, 
although  that  fact  is  obscured  in  the  table  because  the  values  of  MER  round 
to  the  same  two  decimals  (MER  =  .495  in  A,  .496  in  B,  and  .498  in  C) .   (The 
reason  they  are  not  significantly  more  productive  is  that  the  model  assumes 
short  term  gains  in  productivity  from  schedule  pressure,  and  that  effect 
helps  to  counter  the  losses  from  turnover.)   The  feedback  to  and  from  the 
market  is  more  significant,  however.   The  greater  revenue  stream  that 
results  from  lower  product  development  times  allows  a  slightly  greater 
engineering  group  to  be  hired,  and  as  a  group  they  complete  slightly  more 
products  per  year. 

Transferability  of  Results 

The  goal  of  the  analyses  in  section  IV  is  eventually  an  increased 
understanding  about  the  relationships  between  structure  and  behavior  in  a 
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real  product  developnent  group.   The  analyses  suggest  several  potential 
sources  for  rising  product  developnent  times  that  have  not  been  previously- 
acknowledged.   In  the  context  of  very  rapid  corporate  growth  it  is 
apparently  difficult  to  match  accurately  the  size  of  the  engineering  and 
manager  pools  to  the  size  of  the  jobs  they  have  to  perform. 

The  critical  question  for  model-based  analyses  is  their 
transferability:   to  what  extent  should  we  believe  that  policies  that  work 
in  the  model  will  work  in  reality?   The  answer  hinges  on  our  confidence  in 
the  degree  of  match  between  the  real  system  and  the  model. 

One  might  ask,  for  example,  if  a  company  does  not  acquire  managers  in 
a  planned  ratio  to  engineers,  are  analyses  based  upon  the  model  not 
applicable?   The  personnel  from  the  company  that  participated  in  this 
study  could  not  give  an  aggregated  view  of  the  acquisition  of  managers  in 
their  development  group.   They  accepted  the  formulation  in  the  model  as  a 
reasonable  abstraction  and  simplification  suiting  the  model's  purposes,  but 
they  felt  that  in  reality  an  additional  manager  was  acquired  when  it  was 
perceived  that  a  new  job  had  ccme  to  exist  in  the  group.   Does  that  suggest 
that  the  oscillatory  pattern  observed  in  the  model  relating  to  the 
acquisition  of  managers  is  likely  not  to  be  a  contributor  to  that  company's 
rising  product  development  times? 

While  there  is  no  clear-cut  answer,  we  suggest  that  the  way  to  pursue 
answers  is  to  focus  on  the  essential  structure  in  the  model  responsible  for 
the  pattern  of  behavior,  and  to  try  to  compare  it  to  the  corresponding 
essentials  in  the  real  system.   The  essential  source  of  the  oscillations  in 
the  fraction  of  an  engineer's  time  in  organization  and  communication 
activities  in  the  model  is  a  large  negative  feedback  loop  with  seme 
information  and  acquisition  delays  (see  figixre  11  ).   Some  such  negative 
feedback  loop  must  exist  in  the  acquisition  of  managers  in  real  systems  -- 
there  must  be  a  view  of  the  number  of  people  needed  and  some  process  of 
adjusting  actual  numbers  to  that  need,  and  that  structure  tries  to  negate 
or  counteract  deviations  of  actual  considitions  from  desired.   The  critical 
question  is  are  there  sufficient  perception  delays  and  lags  in  the 
adjustment  structure  in  the  real  system  to  produce  the  sort  of  oscillations 
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the  model  exhibits?   And  just  before  a  new  managerial  post  is  created  cmd 
filled,  how  are  the  components  of  that  job  being  handled?  Does  the 
creation  of  the  new  managerial  post  leave  engineers  with  more  time  to 
engineer?  Were  engineers,  in  fact,  handling  some  of  that  administrative 
burden?   Those  who  wish  to  apply  notions  from  this  study  will  have  to 
address  such  questions  in  their  own  contexts. 

We  might  agree  that  transferability  or  applicability  of  the  results 
of  this  modeling  study  depends  on  the  matching  of  essentials,  not  the 
congruence  of  all  details.   Still,  the  extremely  high  level  of  aggregation 
involved  in  the  formulation  of  the  organization  and  communication  burden, 
OCB,  is  a  potential  source  of  a  lack  of  confidence  in  the  model- based 
analyses.   Current  work  is  exploring  formulations  that  cwnpute  OCB  as  a 
function  of  product  team  size  (people  per  product)  as  well  as  the  total 
size  of  the  development  group.   Sources  in  our  reference  company  suggest 
that  team  size  has  a  significant  effect  on  OCB;   they  estimate  that  a 
doubling  in  the  average  size  of  a  product  development  team  would  increase 
the  organization  and  communication  burden  more  than  a  doubling  in  total 
engineering  personnel  (other  things  being  equal). 

Experiments  with  model  reformulations  of  OCB  involving  team  size  as 
well  as  the  total  group  size  have  raised  an  intriguing  set  of  questions 
about  the  nature  of  the  real  system.   Management  systems  must  try  to  match 
the  number  of  managers  with  the  size  of  the  task  they  are  supposed  handle. 
However,  it  seems  in  the  nature  of  real  management  systems  that  it  is  not 
possible  for  a  ccanpany  to  directly  perceive  the  size  of  the  organization 
and  communication  burden.   However  it  is  formulated  in  a  model,  it  must  be 
inferred,  probably  from  the  number  of  people  engaged  in  it  and  the  extent 
of  their  effort.   The  ccaipany  must  try  to  match  the  growth  of  its 
managerial  staff  to  the  growth  of  an  assumed  or  inferred  organization  and 
cummunication  burden.   The  matching  is  made  more  difficult  if  one  assumes 
that  managers  themselves  add  to  the  organization  and  communication  burden 
they  are  supposed  to  discharge. 

Although  investigations  in  reformulations  of  the  model  relating  to 
the  organization  and  communication  burden  are  incomplete,  the  behavior  of 
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the  model  appears  to  remain  much  the  same  as  shown  above.   Again,  a 
fundamental  negative  loop  with  perception  and  action  delays  surrounding  the 
acquisition  of  managers  tends  to  produce  an  oscillatory  pattern  in  the  time 
an  engineer  spends  in  these  nonengineering  activities.   While  some  of  the 
details  differ,  the  basic  structural  insight  remains  unchanged. 

Excess  Capacity 

Perhaps  the  single  most  powerful  notion  to  combat  the  sources  of 
rising  product  development  times  suggested  in  this  study  is  excess 
capacity.   Excess  managerial  capacity  could  move  in  to  absorb  unforseen 
increases  in  the  organization  and  communication  burden  of  an  engineering 
group,  before  engineers  were  forced  to  divert  some  of  their  time  and  energy 
to  more  nonengineering  tasks.   It  would  be  costly,  of  course,  and  it  would 
be  difficult  to  be  sure  the  productivity  gains  and  eventually  revenue 
returns  would  justify  the  additional  managerial  cost.   As  the  summary 
figures  in  table  1  show,  one  might  conclude  that  competing  goals  are 
affected  differently:   in  run  D,  for  example,  market  share  improves  and  the 
company  has  more  products  on  the  market,  but  cumulative  profits  are  down 
compared  to  rim  C. 

Though  perhaps  harder  to  implement,  excess  engineering  capacity  could 
also  be  considered.   It  could  take  the  form  of  a  slight  relaxation  in  the 
some  of  the  pressures  described  in  section  III  that  combine  to  lead  to 
overcommitment  of  resources.   In  judging  product  development  proposals  that 
are  competing  for  the  same  resources,  for  example,  management  could  try 
balancing  incentives  to  underestimate  the  resources  necessary  with 
incentives  to  bid  accurately.   Again  the  critical  question  is  whether  the 
benefits  would  outweigh  the  costs,  and  the  answer  would  undoubtedly  depend 
upon  circumstances. 

In  the  final  analysis  there  is  the  question  of  whether  the  benefits 
that  result  from  holding  down  product  development  times  outweigh  the  costs 
of  the  effort  required.   How  does  the  relative  influence  of  product 
developnent  time  on  revenue,  market  share,  or  other  corporate  bench  marks 
compare  with  the  influences  of  product  availability,  marketing  effort, 
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service,  or  responsiveness  to  consumer  demands?  If  dollars  are  to  be  spent 
improving  the  company's  competitive  position,  should  they  be  spent  to  hold 
down  product  development  times,  or  should  they  be  spent  improving 
production  facilities?  In  focusing  solely  on  the  product  development  group 
and  on  behavior  of  product  development  times  this  study  has  not  addressed 
that  question.   The  leverage  commonly  attributed  to  R&D  in  high-technology 
industries  suggests  (but  does  not  prove)  that  controlling  product 
developnent  times  may  be  worth  the  effort. 
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